\chapter{System Design}
In this chapter we will look into our design and explain the choices we have made and why, as well as some use cases that will help us determine how to model the system's domain model, as well as the database. It will also give us an idea over which method will be needed to be implemented in our webservice.


\section{Use Cases}
The use cases in this system is divided in three types of actors. The first actor is a cinema employee who is at the cinema and sells the customers tickets by an administrative client. The other type of actor is a customer who goes to the cinema website to book a ticket.
 
\subsection{Book Ticket}
Actor: Customer, Staff\\
The customer enters the website and chooses which movie they would like to see. The customer will choose the desired number of ticket(s) and what type of ticket(s). Then the customer will choose where to sit, or let the system automatically find the best available seats. The customer will have to either log in with username and password, create a user, or fill out at least name and phone number. The ticket is now reserved. The customer has the choice to buy the ticket online and skip the line at the cinema. Staff will also have the ability to book and sell tickets through an administrative client.
 
 
%\subsection{Purchase Ticket}
%Actor: Customer
%The customer go to the website and finds a movie and chooses it. Then the %customer will choose how many tickets needed and which type of tickets. Then the customer will choose where to sit, or let the system automatically find the best available seats. Now the customer will have to either log in with username and password, create a user, or fill out at least name or phone number. The ticket is now reserved. Now the customer will fill out credit card information and purchase the ticket.
 
 
\subsection{Cancel Ticket}
Actor: The System \\
The actor finds a reservation and cancels it in case the reservation did not complete successfully or a timeout occured if a user took too long to finish the reservation.

 
%\subsection{Setup Movie Schedule}
%Actor: Cinema employee
%The cinema employee uses the system to administrate the movie schedule.
%To add a new movie the cinema employee will fill out information about the movie, and choose which days the movie will be shown, and what time, and in which hall. If mistakes a made, the information can be deleted or altered.
 
 
%\subsection{Administrate Booking}
%Actor: customer, cinema employee
%The customers can go to the website and handle their reservations. They can make changes to it or delete it. The cinema employee can also log into the cinemas system and administrate the bookings, fx. if a customer calls for assistance, or if a customer visits the cinema and has not ordered the tickets yet.
 
 
%\subsection{Handle ticket purchases}
%Actor: Cinema employee
%The cinema employee uses the system to see how many tickets are sold. The employee can choose a specific date, hall or movie, and the system will calculate the number of sold tickets. 


\section{Domain Model}
In order to develop a cinema booking system, we have chosen to create the following classes in the domain model. The User class will contain information about the customers using the website. When they want to order or buy tickets, they make a reservation. The Show class beneath Reservation is created because the cinema can create a show with more than one movie, e.g. a trilogy. This is the reason show can contain more than one movie. Beneath Show, we have a Hall class with an integer data type. This creates a possibility of expanding the cinema with more halls. The Ticket class is connected to Reservation and every ticket has a ticket number and a unique ID number to prevent fraud. Seat has a seat number and it is connected to a Row class, which also has a number. 

\begin{figure}[H]
\centering
\includegraphics[width=1\linewidth]{img/DomainModel.png}
\caption{Domain Model}
\label{fig:DomainModel}
\end{figure}
\newpage
\section{Relational Model}
We have from our domain model created a relational model to decide how our database will be implemented. The yellow keys are primary keys, and the foreign keys can be seen in navigation properties. We made a new association between the Show- and Ticket class. This association is made so the cinema staff can check how many seats are available in a specific show, without any delay. This can be checked without the new association, by joining Show, then Hall, then Row, then Seat, and lastly Ticket together. But this would take extra calculation time, especially with thousands of tickets every day. Our priority is speed instead of memory saving.

\begin{figure}[H]
\centering
\includegraphics[width=1\linewidth]{img/RationalModel.png}
\caption{Rational Model}
\label{fig:RationalModel}
\end{figure}